Loading SysTrack PowerShell Module in User-Context Scripts
If your Collection Extension or Automation uses SysTrack PowerShell cmdlets, replace relative path imports with the following registry-based resolution pattern:
Old Pattern (No Longer Supported in 11.7+):
# This will FAIL when running as User in version 11.7+
import-module -name "..\..\..\Utilities\SysTrackPS.dll"
New Pattern (Required for 11.7+):
# Load SysTrackPS module.
$node = ('WOW6432Node','')[${env:PROCESSOR_ARCHITECTURE}.StartsWith('ARM')]
$regPath = “HKLM:\\SOFTWARE\$node\Lakeside Software\Deploy”
$lsiPath = (Get-ItemProperty -Path $regPath).InstallDir
$dllPath = “$lsiPath\Utilities\SysTrackPS.dll”
if (!(Test-Path $dllPath)){break}
Import-Module -Name “$lsiPath\Utilities\SysTrackPS.dll”
Why This Works: The registry lookup retrieves the actual installation directory of the SysTrack Agent, ensuring the script can locate SysTrackPS.dll regardless of where the action executes.
NOTE: This change only affects scripts running as User. Scripts running as System continue to execute in the action distribution directory, but the registry-based pattern is recommended for consistency.
Files Within Your Action Package
Relative paths between files inside your action package still work normally. For example, if your action contains MyScript.ps1 and config.txt, you can still use:
$config = Get-Content ".\config.txt"
Only references to files outside the action package (like SysTrackPS.dll) require absolute paths or registry resolution.
On This Page